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PREFACE 


Ti  is  Memorandum  describes  a  parsing  caoability  embedded 
within  the  PL/I  programming  language.  This  extension  allows 
users  to  specify  the  syntax  of  their  parse-requests  in  a 
BNF-like  language  and  the  semantics  associated  with  a  suc¬ 
cessful  parse-request  in  the  PL/I  language. 

The  APAREL  system  has  been  designed  for  a  wide  range  of 
parsing  applications  including  macro  expansion,  symbol  manip¬ 
ulation,  on-line  command  parsing,  analysis  of  programs,  and 
translation  of  programming  languages. 

This  revised  Memorandum,  representing  the  actual  imple¬ 
mentation  of  the  system,  supersedes  the  authors'  APAREL- -A 
Parse-Request  Language,  The  Rand  Corporation,  RM-5611-ARPA, 
October  1968. 

APAREL  has  been  developed  as  a  basic  tool  for  use  in 
man-machine  communication  studies  at  Rand  under  sponsorship 
of  the  Advanced  Research  Projects  Agency. 
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SUMMARY 


This  Memorandum  describes  APAREL,  an  extension  to  an 
algorithmic  language  (PL,/I)  that  provides  the  pattern¬ 
matching  capabilities  normally  found  only  in  such  special- 
purpose  languages  as  SN0B0L4  and  TMG.  This  capability  is 
provided  through  parse-requests  stated  in  a  BNF-like  for¬ 
mat.  These  parse-requests  form  their  own  programming 
language  with  special  sequencing  rules.  Upon  successfully 
completing  a  parse-request,  an  associated  piece  of  PL/I 
code  is  executed.  This  code  has  available  for  use,  as 
normal  PL/I  strings,  the  various  pieces  (at  all  levels)  of 
the  parse.  It  also  has  available  as  normal  PL/I  variables, 
the  information  concerning  which  of  the  various  alterna¬ 
tives  were  successful.  Convenient  facilities  for  multiple 
input-output  streams,  the  initiation  of  sequences  of  parse- 
requests  as  a  subroutine,  and  parse- time  semantic  checks 
are  also  included. 

APAREL  has  proven  convenient  not  only  as  a  general 
string  manipulator  but  also  in  building  a  powerful  SYNTAX 
and  FUNCTION  macro  system,  an  algebraic  language  preprocessor 
debugging  system,  an  cn-line  command  parser,  and  a  translator 
for  Dataless  Programming. 
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I.  INTRODUCTION 


Higher-level  descriptions  of  the  problem  of  compiling 
have  attracted  much  interest  in  the  past  few  years.  Along 
with  the  desire  to  develop  higher-level  specialized  lan¬ 
guages  tailored  to  particular  users,  the  need  has  arisen 
to  develop  similar  specialized  languages  for  the  writing 
of  these  compilers.  In  general,  these  so-called  compiler- 
compiler  languages  are  characterized  by  their  facility  to 
define  in  a  BNF-like  manner  the  syntax  of  the  target  lan¬ 
guage.  In  addition,  they  possess  i  programming  language 
designed  to  operate  on  and  to  direct  the  results  of  the 
parsing. 

With  most  compiler-compilers  a  problem  arises  both  in 
controlling  the  parse  sequencing  and  in  operating  on  the 
results  of  the  parsing.  In  particular,  flexibility  is 
usually  lacking  in  1)  the  specification  of  sequences  of 
parse  attempts,  2)  the  determination  of  the  success  or 
failure  of  a  parse  attempt  on  other  than  purely  syntactic 
grounds,  and  3)  the  specification  of  when  semantic  routines 
should  be  invoked.  Furthermore,  the  semantic  language  is 
usually  a  small  specia] -purpose  language  with  facilities 
for  the  production  of  machine  code.  These  systems  ignore 
such  other,  nonco.npilation  applications  for  parsers  as 
on-line  command  parsers  (which  produce  actions  instead  of 
machine  code) ,  interpretive  parsers  (which  produce  pseudo¬ 
code)  ,  "natural-language"  parsers  (which  produce  semantic 
trees) ,  macro  parsers  (which  produce  source  code) ,  refor¬ 
matting  programs  (which  produce  formatted  listings),  and 
so  on.  In  short,  the  nonmachine-code  generation  applica¬ 
tions  of  parsers  have  generally  not  been  well  handled  by 
the  translator  writing  systems. 

APAREL  attempts  to  provide  a  single  system  for  all 
these  applications  by  providing  the  user  with  a  powerful 
general-purpose  programming  language  (PL/I)  for  performing 
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the  wide  range  of  semantics  required,  and  a  flexible  high- 
level  syntax  language  for  specifying  parse  attempts,  to¬ 
gether  with  facilities  for  controlling  the  sequencing  of 
these  parse  attempts,  determining  success  and/or  failure 
on  both  syntactic  and  semantic  grounds,  invoking  seman  ics 
when  desired,  and  for  manipulating  the  parts  of  a  success¬ 
ful  parse.  Also,  the  familiarity  of  programmers  with  PL/I 
and  the  simplicity  of  the  APAREL  extensions  and  additions 
make  it  feasible  for  potential  users  to  design,  implement, 
and  modify  special-purpose  languages  without  extensive 
learning. 
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II.  APAREL — A  PARSE-REQUEST  LANGUAGE 


Our  view  of  translation  is  composed  of  three  parts: 

1)  A  request  to  find  sequences  of  syntactic  con¬ 
structs  in  the  source  string  to  be  parsed; 

2)  Context-sensitive  validity  checks  to  be  made 
after  successful  syntactic  parses;  (For  example, 
has  the  label  been  defined  before?  Is  the  type 
of  a  variabl'  arithmetic?  etc.) 

3)  Semantic  rout,  nes  to  be  executed  only  if  both 
the  syntactic  parse  and  the  context-sensitive 
validity  checks  are  successful. 

This  view  of  translation,  while  very  general,  is  easy 
for  nonprofessional  translator  writers  (but  experienced 
programmers)  to  use  in  constructing  easily  modifiable 
translators . 

Requests  for  parses  are  specified  :n  a  language  very 
similar  to  BNF  (rather  than  Floyd-Evans  production  lan¬ 
guage)  ,  because  nonprof eusional  translator  writers  tend  to 
conceptualize  the  syntax  of  their  language  top-down  (for 
which  purposes  BNF-type  languages  are  well  suited) .  Pro¬ 
fessional  translator  writers,  on  the  other  hand,  have 
learned  that  the  bottom-up  approach  (for  which  production- 
type  languages  are  appropriate)  is  usually  more  efficient. 
Furthermore,  the  former  tend  to  think  of  both  the.  syntax 
and  semantics  at  the  statement  level. 

To  keep  the  syntax  language  simple,  while  still  allow¬ 
ing  generality  in  describing  conditions  falling  in  the  azy 
area  between  syntax  and  semantics  (which  one  would  lik'  to 
verify  before  accepting  a  parse  made  on  syntactic  grounds 
alone),  we  allow  the  specification  of  "pars ~ -time ’  routines 
that  return  truth  values.  If  they  return  a  value  of  TRUE, 
the  parse  will  contiue.  However,  if  a  value  of  FALSE  is 
returned,  the  parse  will  be  unsuccessful,  just  as  if  the 
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syntactic  parse  failed.  (The  total  parse  may  still  be  suc¬ 
cessful  if  alternatives  are  available  to  the  unsuccessful 
subparse.)  In  addition  to  returning  truth  values,  these 
"parse-time"  routines  may  do  any  semantic  processing  de¬ 
sired.  They  are  written  ir.  the  semantic  language  described 
below. 

The  semantic  routine  associated  with  a  parse  is  acti¬ 
vated  upon  successful  completion  of  that  parse  and  success¬ 
ful  returns  from  all  the  relevant  parse-time  validity  checks, 
if  any,  specified  within  the  parse.  The  code  for  the  seman¬ 
tic  routine  immediately  follows  the  request  for  the  parse  in 
the  syntax  language.  The  semantic  language,  rather  than 
being  a  restricted  special-purpose  language,  is  full  PL/I. 

The  wide  range  of  desirable  "semantic"  actions  resulting 
from  various  syntatic  parses  necessitates  a  general-purpose 
programming  language;  and  a  major  shortcoming  of  most  com¬ 
piler-compilers  has  been  their  restrictions  on  the  semantic 
language. 

To  facilitate  the  semantics,  the  various  pieces  of  the 
successful  parse  are  put  into  normal  PL/I  strings  as  speci¬ 
fied  in  the  syntax  language;  and  the  options  chosen,  where 
alternatives  were  specified  in  the  syntax  language,  are 
made  availabla  in  normal  PL/I  variables. 

DESCRIPTION  OF  PARS^-REQUESTS 

The  syntax  of  the  parse-request  language,  specified  in 
3NF,  appears  in  the  Appendix,  However,  the  following  exam¬ 
ples  are  used  to  describe  the  language  informally  . 

All  parse-requests  begin  and  end  with  a  par3e-delimi- 
nator  (a  double  colon).  After  the  beginning  delirr.inator , 
the  name  of  the  request  {the  parse-request-name)  is  set  off 
by  a  colon.  The  remainder  of  the  parse-request  is  a  list 
of  the  alternative  parses  (parse-alternative-list)  desired, 
separated  by  OR  (|)  symbols.  The  parse-request  is  success¬ 
ful  if  any  one  of  the  alternatives  is  parsed  successfully. 
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These  alternatives  may  be  either  parse-elements  or  lists 
of  parse-elements.  Letting  PE^  represent  a  set  of  parse- 
elements,  we  can  describe  the  following  parse  requests: 

::  A:  PE^PE2  ::  (the  parse-request  named 

"A"  will  succeed  if  and 
only  if  the  parse-string 
contains  PE^  followed  by  PE2) 

::  B:  PE^J  PE,,  ::  (the  parse-request  named 

"B"  will  succeed  if  and 
only  if  the  parse-string 
contains  either  PE^  or  PEj) 

::  C:  PE^ [ PE2PE^PE^  ::  (the  parse-request  named 

"C"  will  succeed  if  and 
only  if  the  parse-string 
contains  either  PE^  or 
the  sequence  PE^E^PE^) 

The  parse-elements  can  either  be  a  parse-group  or  a 
parse-atom.  A  parse-group  is  simply  a  named  or  unnamed 
parse-alternative  list  enclosed  in  brackets  C\"  and  "',"), 
allowing  naming  of  parts  of  a  parse  and  alternatives  within 
a  sequence  of  parse-elements.  The  parse-atoms — the  basic, 
indivisible  components  of  a  parse-reques t--consist  of  literal 
strings,  parse-request  names,  parse-request-sequence  names 
(described  below,  pp.  8-10),  and  primitive  parse-request 
functions;  e.g.,  ARBNO  (arbitrary  but  nonzero  number  of  the 
first  argument  separated  by  the  second  argument,  if  there 
is  more  than  one  occurrence  of  the  first  argument) ,  and  BAL 
(balanced  strings).  These  atoms  are  the  components  that 
determine  whether  a  parse  is  successful  or  not.  The  lit¬ 
eral  strings  require  that  an  exact  match  be  found  between 
the  literal  and  the  corresponding  piece  of  the  parse-string; 
the  parse-request  and  parse-request-sequence  names  require 
that  the  named  parse-request  or  parse-request-sequence  be 
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successful  on  the  corresponding  piece  of  the  parse-string; 
and  primitive  parse-request  functions  require  that  the  cor¬ 
responding  piece  of  the  parse-string  satisfy  the  conditions 
of  that  particular  function.  There  is  no  syntactic  distinc¬ 
tion  ma  ’  2  between  these  atoms.  The  category  determination 
is  made  in  the  following  way:  First,  the  list  of  primitive 
parse-request  functions  is  checked.  If  the  atom  is  not  a 
primitive  parse-request  function,  then  the  list  of  parse- 
names  (both  parse-request  and  parse-request-sequence  names) 
is  checked.  Finally,  if  it  is  not  one  of  these,  it  is  con¬ 
sidered  to  be  a  literal.  This  mechanism  alleviates  the  need 
to  quote  most  literals  within  the  parse-request  language. 

Consider  the  following  set  of  parse-requests  to  parse 
PL/I  uO  statements: 

: :  do_statement :  do  iterative-specification 
while_clause  '  ; ' : : 

::  iterative_specif ication:  variable  =  expression 
(to_clause  by_clause |by_clause  to_clause^  |:: 

::  to_clause:  to  expression):: 

::  by_clause:  by  expression):: 

::  while_clause :  while  '  ( ! expression ')' | : : 

The  do_statement  request  requires  the  sequence  of  atoms 

do  iterative_specification  while_clause  ; 

in  the  parse-string  to  be  successful.  Of  these,  the  middle 
two  are  parse-names  and  invoke  parse-requests  as  they  are 
encountered  in  a  left  to  right  scan.  The  first  and  last 
atoms  are  literals  (because  they  are  not  defined  as  parse- 
names  or  primitive  functions) ,  and  require  exact  matches 
with  a  piece  of  the  parse-string.  The  final  atom  is  quoted 
because  semicolons  are  part  of  the  parse-request  language 
(explained  below) ,  and  the  semicolon  here  is  used  as  a 
literal . 

The  iterative_specif ication  request  requires  either  the 
sequence : 
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1)  Variable=expression 

2)  either  2a.  to_clause 

2b.  by_cl?use 

or  2a.  by _ clause 
2b.  t  i_clause 

or  NULL. 


Variable  and  expression  are  primitives  and  are  defined  as 
specified  in  the  PL/I  language  specification  [1] .  Sim¬ 
ilarly,  a  to_clause  is  the  literal  "to"  followed  by  an 
expression,  or  is  null,  and  a  while_clause  .is  the  literal 
"while"  followed  by  an  expression  enclosed  in  parentheses 
(quoted  because  they  are  part  of  the  syntax  language  and 
are  used  here  as  literals),  or  is  null. 

Thus,  the  do_statement  parse-request  invokes  parse- 
requests  for  iterative_specif ication  and  while_clause ,  and 
iterative_s:  ecif ication  invokes  parse  '*equest.s  for  to_clause 
and  by_ciause  and  functions  calls  for  variable  and  expression. 

Unless  otherwise  specified,  the  parses  allow  an  arbitrary 
number  of  blanks  (including  none)  between  pieces  of  the  parse¬ 
string  and  require  that  the  parse  start  at  the  beginning  of 
the  parse-string  although  it  may  be  satisfied  before  the  end 
of  the  parse-string.  Thus,  with  the  above  set  of  parse- 
requests,  successful  parses  v/ill  occur  on  the  following  parse- 
strings  ; 


ao  I  =  1; 

do  I  =  1  by  5  to  (n-3/2) ; 
do; 

do  whi  le  (A-^B)  ; 


and  will  fail  on  the  following  parse-strings: 


I  =  1  to  10: 

Now  do  I  =  1 ; 
do  I  =  1  to  5 
do  I  =  1  to  5  to  6 ; 


(no  initial  do) 

(no  initial  do) 

(no  semicolon) 

(t.o_clause  followed  by  to  clause) 
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The  portion  of  the  parse-request  language  described  so 
far  allows  fairiy  sophisticated  parse-requests  to  be  speci¬ 
fied  easily  and  naturally  in  a  language  similar  to  the  nor¬ 
mally  used  syntax  description  languages  (BNF  or  IBM's  syntax 
notation).  However,  this  is  not  yet  a  useful  facility,  be¬ 
cause  neither  the  sequencing  rules  for  initiating  parse- 
requests  and  for  making  sequencing  decisions  based  upon  the 
success  or  failure  of  a  parse-request,  nor  the  method  of 
accessing  the  various  parts  of  a  successfjl  parse  have  been 
defined. 

PARSE-REQUEST  SEQUENCING  RULES 

A  parse-request-sequence  is  composed  of  all  parse- 
requests  occurring  in  a  common  do-group  or  block.  This 
does  not  include  any  parse-requests  contained  in  blocks  or 
do-groups  within  the  common  do-group  or  block  forming  parse- 
request-sequences  of  their  own.  The  order  of  parse-requests 
within  a  parse-request-sequence  is  the  same  as  their  lexi¬ 
cographical  ordering  in  the  block  or  do-group.  The  semantic 
portion  of  a  parse-request  is  the  code  between  the  end  of 
the  syntax  portion  of  the  parse-request  and  the  beginning 
of  the  next  parse-request  in  the  parse-requesting-sequence , 
or  the  end  of  the  do-group  or  block  if  there  are  no  more 
parse-requests  in  the  sequence. 

A  parse-request  sequence  begins  with  the  first  parse- 
request.  If  the  initial  parse-request  fails,  its  semantic 
code  portion  is  skipped,  and  the  next  parse-request  in  that, 
sequence  is  tried,  and  so  on,  until  either  a  successful 
parse-request  is  found  or  all  parse-requests  fail.  If  a 
successful  parse-request  is  found,  the  associated  semantic 
code  portion  is  executed;  then,  normally,  the  parse-request- 
sequence  is  terminated  with  a  successful  indication  (see 
Sec.  V,  Additional  Features).  Otherwise,  the  parse-request- 
sequence  is  terminated  with  an  unsuccessful  indication. 
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There  are  three  ways  in  which  a  parse-request-sequence 
can  be  initiated.  The  first  is  as  a  parse-atom  in  a  parse- 
request.  Upon  termination,  its  success-failure  indicator 
is  used  in  determining  which  alternatives,  if  any,  are  suc¬ 
cessfully  parsed.  The  second  is  through  use  of  an  explicit 
command,  INITIATE  PARSE,  which  specifies  which  parse-request- 
sequence  to  initiate  and  can  be  issued  in  any  code  portion. 
Upon  termination  of  the  parse-request-sequence,  its  success 
or  failure  is  available  (see  Sec.  Ill,  Parse  Results),  and 
control  continues  with  the  statement  following  the  INITIATE 
PARSE  command.  The  third  method  is  by  program  control  flow¬ 
ing  into  the  first  parse-request  in  a  parse-request-sequence. 
Upon  complet*  "m  of  the  parse-request-sequence,  its  success 
or  failure  is  available,  and  control  passes  to  the  end  state¬ 
ment  at  the  end  of  the  do-group  or  block  in  which  the  parse- 
request-sequence  occurs.  Thus,  if  it  is  contained  in  an 
iterative  do-group,  control  will  continue  around  in  the  loop 
until  iteration  is  complete.  Otherwise,  in  blocks  or  non¬ 
iterative  do-groups,  control  will  flow  out  the  bottom  of  the 
block  or  do-group  upon  termination  of  the  parse-request- 
sequence. 

In  the  first  two  cases,  in  which  a  parse-request-sequence 
is  explicitly  named,  it  is  specified  by  referring  to  the  label 
(which  must  be  in  the  same  block  as  the  invoking  Ftatement)  of 
the  do-group  or  block  in  which  the  parse-request- sequence  oc¬ 
curs.  If  the  name  of  a  parse-request  is  specified  instead, 
only  that  parse-request  will  be  initiated,  and  no  others  in 
its  parse-request-sequence. 

These  sequencing  rules  allow  the  creation  of  sequences  of 
parse-requests  to  be  attempted,  and  the  control  of  the  execu¬ 
tion  order  of  these  requests  based  on  the  results  of  the 
parses  and/or  explicit  program  control. 

As  stated  previously,  the  semantic  routine  associated 
with  a  parse-request  is  activated  upon  successful  completion 
of  that  parse-request  and  upon  successful  return  from  all  the 
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relevant  parsc-Lime  validity  checks,  if  any,  specified 
within  the  parre-request .  This  is  true  whichever  way  the 
parse-request  is  initiated.  Thus,  if  a  parse-request,  Pi, 
is  initiated  as  a  parse-atom  or  a  parse-request,  P2,  and 
if  it  is  successful,  then  its  semantic  routine  will  be  ini¬ 
tiated  at  that  point,  in  the  midst  of  the  parse  of  P2. 
Semantics  thus  can  be  initiated  at  any  point  during  a  parse, 
givinq  the  user  considerable  flexibility.  However,  care 
must  be  exercised  when  specifying  "intermediate"  semantics 
because  the  parse  may  fail  later  in  the  parse  element  list, 
which  contained  the  parse-request  that  invoked  the  seman¬ 
tics,  and  either  move  on  to  the  next  alternative  or  fail 
completely. 
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III.  PARSE  RESULTS 


APAREL  also  contains  capabilities  to  make  the  results 
of  a  successful  (or  unsuccessful)  parse  available  to  the 
code  portions  of  the  language.  This  information  is  of  two 
kinds:  1)  pieces  of  the  string  parsed,  and  2)  information 

about  which  alternatives  were  successful  in  the  parse. 

Various  parse-elements,  such  as  parse-request-sequences, 
parse-requests,  parse-alternatives,  and  parse-groups,  can 
have  names  specified  in  APAREL.  These  names  are  the  means 
by  which  the.  semantic  code  portions  can  utilize  information 
about  a  parse.  If  "NAME"  is  the  name  of  one  of  these  parse- 
elements,  then  after  a  parse,  a  PL/I  varying  length  string 
variable  with  the  same  name  will  contain  that  portion  of  the 
parse-string  corresponding  to  the  named  parse-element.  (In 
the  case  of  a  parse-request-sequence,  the  name  is  both  the 
name  of  the  result  string  and  the  label  of  the  DO-hlock. 
APAREL  contextually  resolves  all  uses  of  this  name  to  re¬ 
move  any  ambiguity.)  Also,  a  PL/I  variable,  whose  name  is 
" NAME_OPT ION "  (i.e.,  !'_OPTION"  is  appended  to  the  end  of 

the  name  of  the  parse-element) ,  will  contain  the  index  of 
the  alternative  selected  within  the  parse-element.  Thus 
the  semantic  portions  can  manipulate  desired  portions  of 
the  parse-string  through  PL/I's  normal  string-handlinci  ca¬ 
pabilities,  and  can  iterrogate  any  portion  of  the  parse- 
tree  to  determine  which  alternatives  were  selected. 

In  applications  with  large  syntax  specifications, 
changing  the  syntax — either  by  addition  or  deletion  of  an 
alternative  from  the  syntax--can  affect  the  semantics,  be¬ 
cause  alternative  determination  is  made  on  an  indexed 
basis;  and  altering  the  syntax  alternative  alters  the  in¬ 
dexing.  To  alleviate  the  problem,  APAREL  allows  the  user 
to  label  any  or  all  of  the  alternatives.  If  a  labeled  al¬ 
ternative  is  selected,  then  the  OPTION  variable  for  that 
group  will  contain  the  name  of  the  alternative  selected 
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rather  than  its  index  (APAREL  contextually  resolves  all 
uses  of  this  variable  so  that  it  can,  in  effect,  take  on 
either  string  or  numeric  values) .  This  naming  correspon¬ 
dence  is  invariant  under  additions  or  deletions  to  the  set 
of  alternatives. 
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IV.  PARSE-TIME  ROUTINES 


Sometimes  success  or  failure  of  a  parse  cannot  be  made 
on  purely  syntactic  grounds  alone;  or,  it  is  desired  to  per¬ 
form  some  semantic  operations  during  a  parse.  For  these 
reasons,  the  parse-time  facility  has  been  included  in  APAREL. 
Parse-time  routines  are  indicated  in  a  parse-element  by 
placing  the  parse-time  routine  name  followed  by  its  argu¬ 
ments,  if  any,  enclosed  in  parentheses  after  a  semicolon  at 
the  end  of  the  parse  element.  The  parse-time  routine  will 
be  initiated  if  and  only  if  the  parse-element  in  which  it 
occurs  was  successfully  parsed.  The  initiation  results  in 
a  function  call  of  the  parse-time  routine,  passing  its  ar¬ 
guments,  if  any.  The  parse- time  routine,  like  the  semantic 
portions  of  APAREL,  is  'oded  in  full  PL/I  and  can  make  use 
of  all  the  facilities  of  APAREL,  such  as  initiating  parse- 
requests,  manipulating  parse-strings,  and  interrogating  the 
parse-trees.  In  addition,  the  parse-time  routine  can  per¬ 
form  any  semantics  desired  and  return  a  true  or  false  value 
indicating  whether  the  parse-element  to  which  it  is  at¬ 
tached  should  be  considered  successfully  parsed. 

Since  parse-request-sequences  initiated  in  the  syn¬ 
tactic  portion  of  a  parse  can  be  a  block  or  a  do-group  that 
may  begin  with  a  code  section  or  may  not  contain  any  parse- 
requests  at  all,  these  parse-request-sequences  can  be  con¬ 
sidered  parse-time  routines  that  return  a  success  or  failure 
indication  (and  are  formally  the  same  as  the  parse-time  rou¬ 
tines  discussed  above).  Both  ways  of  specifying  these 
parse-time  routines  have  been  allowed  in  APAREL,  enabling 
users  to  choose  the  one  corresponding  to  their  way  of  con¬ 
ceptualizing  its  function  in  their  particular  application. 
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V.  ADDITIONAL  FEATURES 


In  the  semantic  portions  of  APAREL,  very  often  one 
would  like  to  output  a  modified  or  "translated"  version  of 
the  parse-string.  To  make  this  operation  simpler,  a  spe¬ 
cial  variable,  TRANSLATION,  has  been  defined;  and  whenever 
an  assignment  is  made  to  this  variable,  the  value  assigned 
is  output  to  the  SYSPRINT  data  set.  For  more  flexibility, 
the  user  may  define  additional  variables  as  being  output 
variable  of  specified  size  and  associated  with  a  specified 
file.  When  an  assignment  is  made  to  one  of  these  variables, 
if  the  value  can  be  added  to  the  end  of  the  present  string 
value  without  exceeding  the  maximum  size  of  the  variable, 
then  the  new  value  is  concatenated  onto  the  existing  value. 
If  not,  then  the  existing  value  is  output  on  the  file  spec¬ 
ified,  and  the  new  value  becomes  the  value  of  the  variable. 
If  the  size  is  not  specified,  then  outputting  occurs  with 
every  assignment.  If  neither  a  file  nor  a  size  is  speci¬ 
fied,  then  a  user-defined  procedure  of  the  same  name  as  the 
output  variable  is  called  with  the  new  value  as  the  argu¬ 
ment.  This  allows  the  user  to  define  arbitrarily  complex 
procedures  for  outputting,  and  corresponds  to  the  updating 
routine  (left-hand  size  function)  definitional  capability 
of  Dataless  Programming  [2]  and  CPL  [3]. 

Similarly,  for  input,  a  variable,  PARSE_STRING,  will 
be  automatically  defined  to  hold  the  input  to  be  parsed. 

When  the  amount  of  input  in  thii*  variable  falls  below  a 
system-defined  limit,  new  input  will  be  concatenated  to  the 
variable  to  fill  it  out  to  its  maximum  size.  The  user  nay 
define  additional  input  variables  together  with  their  mini¬ 
mum  sizes,  maximum  sizes,  and  file  fron  which  input  is  to 
come.  If  the  minimum  and  maximum  sizes  are  not  specified, 
references  to  the  input  variable  will  invoke  a  user-defined 
accessing  function  of  arbitrary  complexity,  a  la  Dataless 
Programming.  These  minimum  and  maximum  sizes  limit  the 
amount  of  backtracking  that  can  occur. 
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The  user  also  can  control  which  of  several  input  sources 
is  used  via  the  CONSIDER  command.  He  may  later  re-establish 
an  input  source  via  the  RECONSIDER  command.  These  commands 
stack  and  unstack  respectively  which  input  source  is  being 
parsed.  CONSIDER_LEVEL  contains  the  rumber  of  input  sources 
so  stacked,  and  CONSIDER_STRING  is  an  array  containing,  in 
ascending  order,  the  names  of  those  stacked  input  sources. 

In  parsing  there  are  normally  three  requirements  for 
blank  separation  between  the  individual  segments  of  the 
parse-string  matched  by  parse-atoms.  The  first  is  that  no 
blank  may  occur  between  the  segments.  This  is  indicated  in 
a  parse-request  by  placing  a  minus  sign  between  the  parse- 
elements.  The  other  two  normal  blank-separation  requirements 
are  that  either  any  number  of  blanks  (perhaps  none) ,  or  at 
least  one  blank  (perhaps  more) ,  separate  the  segments.  Since 
the  need  for  each  of  these  requirements  is  highly  application 
dependent,  APAREL  allows  the  user  to  define  the  normal  mode 
(used  between  pars^-elements  unless  otherwise  specified)  and 
to  request  the  other  requirement  by  placing  a  period  between 
the  parse-elemenls .  The  normal  mode  is  set  by  either  NORMAL 
SEPARATION  IS  0  or  NORMAL  SEPARATION  IS  1  command-  The  de¬ 
fault  setting  is  NORMAL  SEPARATION  IS  1. 

Similarly,  the  cwo  normal  ways  to  view  the  semantic  code 
portion  are  either  as  open  or  closed  subroutines.  In  an  open 
subroutine,  flowing  out  of  the  bottom  of  a  semantic  code 
portion  into  a  parse-request  initiates  that  parse-request. 
Whereas  in  a  closed  subroutine,  flowing  out  the  bottom  of  a 
semantic  code  portion  into  a  parse-request  effects  a  return 
to  the  caller  of  the  parse-request  whose  semantics  have  just 
completed.  APAREL  allows  a  user  to  define  which  of  these  two 
modes  he  is  using  via  the  SEMANTICS  OPEN  and  SEMANTICS  CLOSED. 
The  default  setting  is  SEMANTICS  CLOSED. 

Both  the  SEPARATION  and  SEMANTICS  commands  are  compile¬ 
time  commands  and  affect  the  interpretation  of  all  lexico¬ 
graphically  following  parse-requests  in  the  current  or  con¬ 
tained  blocks  or  do-groups,  until  either  the  end  of  the  block 
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or  do-group,  or  another  node  command,  overrides  the  present 
normal  mode . 

Within  a  semantic  code  portion,  the  user  may  desire  to 
initiate  a  remote  parse-request,  or  to  terminate  the  seman¬ 
tics  for  the  present  parse.  These  capabilities  are  avail¬ 
able,  respectively,  through  the  INITIATE  PARSE  and  TERMINATE 
PARSE  commands . 

Tne  TERMINATE  PARSE  command  is  also  used  to  specify  the 
success  or  failure  of  a  parse-request.  TERMINATE  PARSE 
SUCCESSFULLY  indicates  a  successful  termination,  while  TERMI¬ 
NATE  PARSE  UNSUCCESSFULLY  indicates  an  unsuccessful  parse. 
TERMINATF  PARSE  with  neither  operand  specified  defaults  to 
TERMINATE  PARSE  SUCCESSFULLY.  Thus,  a  parse-request  can  be 
declared  unsuccessful  in  three  ways:  1)  in  the  syntactic 
specification  of  the  parse-request  when  a  syntactic  parse 
is  unsuccessful;  2)  in  a  parse-time  routine;  or  3)  in  the 
semantics  of  a  parse-request.  The  parse  is  successful  only 
if  none  of  these  indicates  an  unsuccessful  parse. 

When  initiating  a  parse-request-sequence,  a  user  often 
wishes  to  be  able  to  inspect  and  manipulate  the  results  of 
the  parse-requests  before  accepting  any  translation  produced. 
Since  these  parse-requests  should  not  (and  need  not)  know 
that  they  have  been  initiated  from  above,  they  must  be  able 
to  create  translations  just  like  any  other  parse-request. 
Therefore,  the  user  needs  a  way  of  telling  APAREL  to  redi¬ 
rect  the  translation  (or  output  variables)  of  any  parse- 
request.  This  redirection  causes  the  translation  produced 
for  the  specified  output  variables  to  be  collected  into  the 
specified  strings  for  review  and/or  manipulation  by  the  ini¬ 
tiating  routine.  This  redirection  is  specified  as  additional 
operands  (of  the  form  x  IN  y  ,  and  separated  by  'AND'  ) 
to  the  initiate  parse-command.  For  example: 

INITIATE  PARSE  k  COLLECTING  translation  IN  s  AND 
output  IN  def; 
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The  parse-request-sequence  named  k  will  be  initiated.  All 
translation  it,  or  any  parse-request  it  initiates,  produces 
in  the  output  variable  named  "translation"  will  be  collected 
instead  in  the  string  named  "s".  and  all  translation  produced 
in  the  output  variable  named  "output"  will  be  collected  in¬ 
stead  in  the  string  named  "def". 

Finally,  by  placing  a  dollar  sign  ($)  in  front  of 
parse-names,  parse-time  routine  names,  or  parse-atoms,  the 
user  can  indicate  indirection;  i.e.,  the  parse-name,  parse- 
routine  name,  or  parse-atom  specified  is  the  contents  of 
the  named  string.  This  facility,  accomplished  via  a  run¬ 
time  symbol  table  of  all  parse-related  names  (which  must  all 
be  unique) ,  provides  considerable  flexibility  for  users  de¬ 
siring  to  alter  the  parse-requests  dynamically.  It  also 
facilitates  context-sensitive  parses  requiring  rep~+  uion  of 
a  parse-element  within  the  input  string. 
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VI.  EXAMPLES 


One  use  of  APAREL  is  as  a  macro  processor,  handling 
macros  of  the  type  commonly  referred  co  as  SYNTAX  and/or 
FUNCTION  macros  [4].  In  such  an  application,  a  user  passes 
the  macros  over  the  source  text,  translating  those  portions 
that  satisfy  the  macro  syntax  while  leaving  the  rest  of  the 
text  undisturbed.  APAREL  is  easily  restricted  to  this  mode 
by  defining  a  parse-request  that  picks  off  source-language 
statements,  one  at  a  time,  from  the  input  stream.  The  re¬ 
sult  of  this  parse,  a  single  source-language  statement,  is 
then  passed  through  the  various  macros  that  produce  the  de¬ 
sired  translation  when  a  parse  request  for  a  macro  is  sat¬ 
isfied.  If  the  source  statement  passes  all  the  way  through 
the  macros  without  matching,  it  is  output  unmodified.  As¬ 
suming  the  parse- request ,  PLI_statement ,  has  been  predefined 
and  will  pick  off  one  PL/I  statement  at  a  time,  the  follow¬ 
ing  is  an  APAREL  program  that  acts  as  a  SYNTAX  and  FUNCTION 
macro  processor  for  any  parse-requests  defined  in  its  body. 

/*  Method:  PL/I  statements  are  picked  off  the  input  stream 
one  at  a  time  and  used  as  the  parse-string  input  for 
the  user-defined  syntax  and  runction  macros  contained 
in  the  parse-request-sequence  USER_MACROS.  If  no 
parse-request  ii.  this  parse-request-sequence  is  suc¬ 
cessful,  then  the  PL/I  statement  is  output.  Otherwise, 
the  translation  produced  is  added  to  the  front  of  the 
string  RESCAN.  If  this  string  is  not  already  being 
CONSIDERed  as  the  input  string  from  which  PL/I  state¬ 
ments  are  picked  off,  it  is  so  CONSIDERed.  Thus  all 
PL/I  statements  in  the  translation  produced  by  the 
USER  MACROS  are  processed  before  any  more  is  taken 
from  the  original  input  source.  After  RESCAN  has  been 
exhausted,  the  original  input  source  is  RECONSIDERed  */ 
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next__PLl_statement : 

INITIATE  PLl_statement ;  /*  get  next  PL/I  statement*/ 

IF  PLl_statement_option  =  0  /*  was  the  parse  successful*/ 
THEN  DO;  /*  no,  end  of  input  must  have  been  reached*/ 

IF  CONSIDERED_STRING  (CONSIDER_LEVEL) =' rescan ' 
THEN  DO;  /‘reconsider  the  original 
input  string*/ 

RECONSIDER; 

GO  TO  next_PLl_statement ; 

END; 

ELSE  /*  we  have  exhausted  the  original  input 
string*/ 

TERMINATE  PARSE;  /*  terminate  the  parse 
in  this  manner  in  case  we  were 
initiated  by  someone,  and  are  not 
the  top-level  routine*/ 

END; 

ELSE  DO;  /*  parse  was  successful,  we  now  have  a  single 

PL/I  statement*/ 

CONSIDER  PLl_statement ;  /*  use  result  of  ?L/I  statement 

as  parse-string  for  user_macrcs*/ 

INITIATE  user_macros  COLLECTING  translation  IN  partial_ 

translation;  /*  initiate  users 
syntax  and  function  macro  parse- 
request-sequence  contained  in  the 
block  or  dc_group  labeled  "user- 
macros".  The  translation  output 
of  these  macros  is  collected  in 
the  PL/I  string  "partial_trans- 
lation"*/ 

RECONSIDER;  /*  stop  considering  PLl_statement  and 
reconsider  the  parse-string  in 
effect  before  it*/ 
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If  user_macros_option-i=  0  THEN  DO;  /*  one  of  the  parse- 

requests  in  the  user_macros  parse- 
request-sequence  was  successful*/ 
rescan  =  partial_translational | | rescan;  /*  add 
partial  translation  to  front  of 
rescan  string  so  that  it  will  be 
retranslated  first.  Notice  that 
this  defines  a  depth  first 
translation*/ 

IF  CONSIDEREDJSTRING  (CONSIDER_LEVEL)-»  =  'rescan' 

/*  is  rescan  the  currently  considered 
parse-string*/ 

THEN/*  no  it  is  not  the  currently  considered 
string*/ 

CONSIDER  rescan;  /*  make  it  the  current 
parse-string*/ 

GO  TO  next_PLl_statement ; 

END; 

ELSE  DO;  /*  none  of  the  parse-requests  in  the  user-macros 

parse-request-sequence  were  successful*/ 
TRANSLATION  =  PLl_s tatement ;  /*  output  the 

PL1  statement  that  did  not  match*/ 

GO  TO  next_PLl_s tatement; 

END; 

Continuing  the  above  example,  two  parse-requests  are 
shown  below,  both  of  which  provide  translations  into  PL/I. 

They  are  placed  in  the  do_group  labeled  "user_macros"  to 
conform  to  the  preceding  example/s  initiation  command.  The 
first  is  a  syntax  macro  that  translates  increment  or  decre¬ 
ment  commands,  and  the  second  is  a  functional  macro  that 
translates  various  notations  for  asking  if  a  value  is  equal 
to  one  of  a  number  of  items.  Notice  that  the  only  differ¬ 
ence  between  syntax  and  function  macros  is  that  syntax 
macros  require  successful  parses  to  be  anchored  to  the 
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beginning  of  the  parse-string,  while  functional  macros  al¬ 
low  successful  parses  anywhere  within  the  parse-string. 

The  annotated  parse-requests  are  given  below,  followed 
by  a  set  of  example  input  parse-strings  with  their  trans¬ 
lations  : 

user_macros:  DO;  /*  begin  labeled  do  group  that  defines  a 

parse- sequence*/ 

NORMAL  SEPARATION  IS  1;  /*  unless  otherwise  specified 

parse-elements  must  be  separated 
by  one  or  more  blanks*/ 

SEMANTICS  CLOSED;  /*  upon  reaching  the  end  of  the  se¬ 
mantics  of  a  parse-request,  auto¬ 
matically  generate  a  terminate- 
parse  command*/ 

::  Increment_command:  command_type  <updated_variable : 

subscripted  variable)  by  (increment 
amount:  ARB's.';'  /*  ar.  increment 

command  is  a  command  type  followed 
by  a  possibly  subscripted  variable, 
called  "updated_variable" ,  followed 
by  the  literal  "BY"  (literal  since 
it  is  not  defined) ,  followed  by  an 
arbitrary  string  called  "increment 
amount",  followed  by  a  semicolon. 
(The  semicolon  has  to  be  quoted 
since  it  is  part  of  the  parse- 
request  language.)  The  period 
indicates  that  a  space  is  not  re¬ 
quired  in  front  of  the  semicolon.*/ 

IF  command_type_option  =  "increment  command"  /*  was  the 

option  in  command_type  labeled 
"increment_command"  chosen*/ 

THEN  /*  yes  this  is  an  increment  command*/ 

translation  =  updated_variable | | ' = 1 | | updated_ 
variable j | '+'| j increment-amount 
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/‘output  PL1  assignment  for 
incrementing  variable*/ 

ELSE  /*  no,  must  be  decrement  command*/ 

translation  =  updated_variable  |  |  '  =  ' | | updated_ 

variable  j  | ' - ( ' | | increment_amount 
j  !');'?  /‘output  PL/I  assignment 
for  decrementing  variable  enclosing 
increment_amount  in  parentheses*/ 

/*  the  next  statement  is  a  parse-request  in  the  same 

block  or  do  group  as  the  present 
parse-request;  therefore,  it 
indicates  the  end  of  this  semantic 
code;  and  since  semantics  have  to 
be  set  closed,  it  automatically 
generates  a  terminate-parse 
command. */ 

/*  this  parse-request  will  be  activated  if  the  preceding 

parse-request  failed*/ 

one_of ; (front : ARB ) (x:  subscripted_variable \  (is | is  among|.=. 

alternative_list(back:ARB'> : ; 

/*  a  one_of  function  macro  is  an 
arbitrary  string  (the  ARB  primitive 
parse-request  function  matches  the 
smallest  string  that  allows  the 
rest  of  the  parse-request  to  be 
successful;  this  may  require 
backup  and  repeated  attempts,  each 
time  increasing  the  length  of  the 
string  matched  by  _ne  ARB  parse- 
request  function)  named  "front" 
followed  by  a  subscripted  variable 
named  "x"  followed  by  either  "is", 

"is"  followed  by  "among",  or  by  "=". 
This  is  followed  by  an  alternative_ 
list  followed  by  an  arbitrary  string 
named  "back".  The  separation  between 
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these  elements  is  one  or  more  blanks — 
except  for  the  equal  sign,  which  may 
have  zero  or  more  blanks  on  either 
side  of  it  as  indicated  by  the  normal 
separation  override  notation  (the 
periods ) . */ 

translation  =  front | | PLl_alternatives  |  |  back ;  /*the 
string  "PLl_alternatives"  replaces 
the  function  macro  in  the  parse¬ 
string,  and  the  result  is  output  as 
the  translation  of  the  parse-string. 
The  PLl_alternatives  string  was 
built  up  in  the  semantic  portion  of 
the  alternative_list  parse-request 
shown  below*/ 

END  user_macros ;  /*  this  is  the  end  of  the  do-group. 

It  indicates  the  end  of  the  semantic 
portion  of  the  one_of  parse-request; 
and,  since  semantics  are  closed,  it 
automatically  generates  a  terminate 
parse-command  for  that  parse-request. 
If  this  parse-request  had  failed, 
then,  since  it  was  the  last  parse- 
request  in  the  parse-request-sequence 
the  sequence  would  have  failed.*/ 

/*  the  following  are  parse-requests  referred  to  above. 

Since  they  are  defined  in  another 
do-group  or  block  than  the  preced' 
parse-requests,  they  do  not  form 
part  of  its  parse-request-sequence.*/ 
subscripted_variable :  variable  <. '  {'  .BAL. ' )  '  .  |  : ;  /*a 

subscripted  variable  is  a  variable 
followed  by  a  left  parenthesis 
followed  by  an  arbitrary  strirg 
balanced  with  parentheses  followed 
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by  a  right  parenthesis  or  a  variable 
followed  by  a  null.  The  parentheses 
and  the  balanced  string  do  not  have 
to  be  separated  by  blanks.  There 
are  no  semantics  specified  for  this 
parse-request. */ 

command_type :  (  increment_command  :  increment  |  i  1  inc  >  | 

A3ecrement_command :  decrement j  d|  dec*)  : 
/*  a  command  type  is  either  an 
increment_command  or  a  decrement_ 
command.  These  two  types  can  each 
be  indicated  in  one  of  three  ways: 
"increment",  "i",  or  "inc"  and 
"decrement",  "  or  "dec".  There 
are  no  semantics  specified  for  this 
parse-request  */ 

alternative_list :  Initial_semantics  ARBNO  (alternative , 

,'\  or  ')  ::  /*  an  alternative^ 

list  is  an  initial_semantics  followed 
by  an  arbitrary  number  (with  a 
minimum  of  one)  of  alternatives 
separated  by  either  commas  or  the 
literal  "or".  The  parse-request, 
initial_semantics ,  does  not  perform 
any  parsing,  but  is  used  to  initial¬ 
ize  the  string,  PLl_alternative , 
used  in  the  semantics  of  "alterna¬ 
tive".  There  are  no  semantics 
specified  for  this  parse-request.*/ 

alternative:  expression:  /*  an  alternative  is  an  ex¬ 

pression.  Its  semantics  follow. 

The  same  effect  could  have  been 
achieved  by  replacing  alternative 
in  the  parse-reque  it  alternative_list 
by  expression;  aiternative_semantics 
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where  alternative_semantics  would  be 
the  name  of  the  following  semantic 
routine.  The  choice  is  left  to  the 
user  depending  on  his  particular 
basis . */ 

if  -i  first_alternative  then  PLl_alternatives=PLl_ 

alternatives | | ' ! ' I  I x II ' = ' I  I  expression; 
/*  the  alternative  is  added  to  the  end 
of  the  alternatives  already  found. 

It  is  separated  from  the  preceding 
alternatives  by  " | " ,  and  consists  of 
the  subscripted  variable  (the  value 
of  x  from  the  parse-request,  "one_of") 
followed  by  an  equal  sign  followed 
by  an  expression  just  parsed  above.*/ 
ELSE  DO:  /*  this  is  the  first  alternative*/  first_ 

alternative  =  'O'B;  /*  indicate  no 
longer  first  alternative*/ 
PLl_alternatives  =  x| | | |  expression; 
/*  PLl_alternatives  is  set  to  the 
first  alternative  found*/ 

END; 

TERMINATE  PARSE;  /*  indicate  er.d  of  semantics*/ 
initial_semantics :  DO;  /*  initial-semantics  is  a  parse-request- 

sequence  containing  no  parse-request*/ 
f irst_alternative  »  ' l'B;  /*  indicate  parse-request  was 

successful*/ 


END; 


r 
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VII.  TRANSLATION  RESULTS 


Using  the  APAREL  program  defined  in  Sec.  VI,  we  indi¬ 
cate  below  the  translations  that  would  result  for  various 
input  examples.  If  the  input  passes  through  unchanged,  the 
translation  entry  is  left  blank  to  facilitate  recognition. 


input 

translation 

comments 

increment  x  by  5; 

X  =  X+5; 

d  abc  by  x-4; 

abc  =  abc  -  (x-4); 

the  decrement 

translation 

supplies  paren¬ 
theses  around  the 

decrement  amount. 

i  def  by  7; 

no  separating 
blank  after  'by' 

decrement  by  3; 

'by'  is  picked 

up  as  the  sub¬ 
scripted  variable, 

but  the  parse  then 

fails  because  'by* 

cannot  be  found. 

if  abc  is  x-3  or 

if  abc  =  x-3  | 

0  then  do; 

abc  »  0  then  do; 

R  =  (def  is  among 

R  =  (def  =  1  |  def  =  2 

l,2,Z-4  or  9) ; 

J  def  =  Z-4  i 
def  =  9) ; 

when  h  =  5,  or  7 

when  h  =  5  |  h  or 

comma  after  5 

then  do; 

7  then  do; 

causes  parser 

to  pick  up  "or" 
as  an  expression 

rather  than  as  the 

1 

separator  between 
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input 


if  x  is 

if  x  =  1 
then  i 


translation 


3, >5,  or  0 

or  4  if  x  =  1  |  x  =  1 

x  by  x-1;  then  x  =  x+x-1; 


comments 

expressions.  The 
syntax  of  the 
functional  macro 
should  be  cor¬ 
rected  to  prevent 
this  error.  Notice 
how  this  error  is 
reflected  in  the 
translation; 

" >5"  is  not  an 
expression. 
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VIII.  IMPLEMENTATION 


The  initial  imp] ementation  of  APAREL,  which  has  been 
completed  on  an  IBM- 360  computer,  consists  of  two  parts: 

1)  a  preprocessc”  that  converts  APAREL  programs  into  equiv¬ 
alent  legal  PL/I  pr  grams  with  external  calls  for  parse- 
requests,  and  2)  the  run-tim  ■  parser,  whi  h  provides  APAREL' s 
parsing  capabilities.  The  preprocessor  is  an  APAREL  program 
that  was  bootstrapped  into  operation,  and  the  run-time  parser 
is  an  assembly-language  program.  The  current  implementation 
of  each  of  these  parts  imposes  the  following  restrictions  on 
the  full  APAREL  language . 

1)  The  BAL  primitive  parse-request  function  is  not 
implemented. 

2)  The  scan  of  parse-requests  is  strictly  left  to 
right.  Thus,  in  the  parse-request 

^a|b>c 

if  A  is  matched,  B  will  be  skipped;  if  C  then 
fails,  the  sequence  B  followed  by  C  will  not  be 
tried.  This  can  be  remedied  ny 
<  AC | BC) 

3)  The  parser  matches  the  maximum  string  possible. 

This  applies  only  to  the  nonliteral  matches;  e.g., 
ARBNO  and  the  blank  scan,  which  mat-ch  as  much  as 
possible.  Note  that  this  will  prevent  the  parse- 
request 

ARBNO  (A ,  "  )  A 

from  being  parsed  successfully  because  the  aroitrary 
number  of  A's  separated  by  NULLs  will  include  all 
such  A's  in  the  input,  forcing  the  final  A  after 
the  ARBNO  to  fail. 

4)  Left-recursion  is  handled  in  a  rather  unique  way. 

The  state  of  the  parser  is  determined  by  two  vari¬ 
ables:  1)  the  position  in  the  input  string,  and 
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2)  the  position  in  the  parse-request.  Before  at¬ 
tempting  a  match  for  any  alternative,  the  parser 
checks  to  see  if  the  present  state  has  occurred 
before  (during  the  current  initiation  of  the 
original  parse-request).  If  it  has,  a  left  recur¬ 
sive  loop  has  occurred,  and  the  parr  r  simply 
moves  on  to  the  next  alternative  to  break  this 
left  recursive  loop.  This,  therefore,  would  cause 
the  rule 

number:  number  digit| digit 
to  fail  on  more  than  two  digit  numbers.  Tins  can 
be  remedied  by  using  the  ARBNO  function,  which 
allows  iterative  specification  rather  than  nested 
recursive  definition.  Thus, 
number:  ARBNO (digit ," ) 

A  number  is  an  arbitrary  nonzero  number  of  digits 
separated  by  NULLs.  Or  even  more  elegantly: 

expression:  ARBNO (express ion, operator ) | (expression) 
|  variable |  number 
J  unary_operator  expression 
An  expression  is  an  arbitrary  nonzero  number  of 
expressions  separated  by  operators,  a  parenthesized 
expression,  a  variaole,  a  number,  or  a  unary  opera¬ 
tion  followed  by  an  expression. 
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Appendix 

BNF  DEFINITION  OF  APAREL'S  SYNTAX  LANGUAGE 


/PARSE_REQUEST''  :=  '  PARSE_DELIMINATORN  (PARSE_NAME )  : 

(PARSE_ALTERNATIVE_LIST)(PARSE_DELIMINATORN 
(PARSE_ALTERNATIVE_LIST)  :=  /PARSE_ALTERNATIVF_NAME ) 

( PARSE_ELEMENT  LIST)  |  (PARS  _ALTERNATIVE_NAME) 

( PARSE_ELEMENT_LIST)  '  j  '  ( PARSE_ALTERNATIVF_LISTN> 

1  PARSE_ELEMENT  LIST)  :=  ( PARSE_ELEMENT'>  | 

(  PARSE_ELEMENT  ) ;  (  PARSE_TIME_ROUTINE__NAME)  | 

(  PARSE_ELEMENT)(PARSE_ELEMENT  LIST)  j 
( PARSE_ELEMENT >.  ( PARSE  ELEMENT_LIST) 

<'PARSE_ELEMENT'>  :=  (PARSE_ATOM)  J  (  PARSE_GROUP > 

( PARS E_G ROUP )  (  PARSE_ALTERNATIVE_LIST  )  ')'  | 

'( '  ( PARSE-NAME >:<PARSE_ALTERNATIVE_LIST>  ' N ' 

(  PARSE_ATOM  )  (  PARSE_NAME  )  |  (TEXT  LITERAL) 

( PARSE_NAME )  :=(PL/1  IDENTIFIER) 

(PARSE_ALTERNATIVE  NAME')  :=  ((PL/1  IDENTIFIER)) 

(PARSE_DELIMINATORy  :=  :: 

•  PARSE-TIME  ROUTINE  NAME)  :=  (NAME  OF  A  PL/1  BIT  VALUED  FUNCTION  N 
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